home *** CD-ROM | disk | FTP | other *** search
/ Amiga Tools 2 / Amiga Tools 2.iso / tools / packer / xpk / xpkrake_v1.5 / xpkrake.doc next >
Text File  |  1995-03-09  |  6KB  |  140 lines
  1.  
  2.                                     RAKE
  3.                          A cruncher of the LZ77 family
  4.                              for the XPK-package
  5.                                 Version 1.5
  6.                      Copyright 1995 by Karsten Dageförde
  7.  
  8.                               Status: FREEWARE
  9.  
  10.  
  11.  
  12.                              License/Disclaimer
  13.                              ------------------
  14.  
  15.    This  library  may  be  freely  distributed, as long as it is kept in its
  16. original,  complete,  and  unmodified  form.  It may NOT be distributed in a
  17. commercial package of any kind without my permission.
  18.  
  19.    This  program  is  distributed  in  the  hope that it will be useful, but
  20. WITHOUT  ANY  WARRANTY; without even the implied warranty of MERCHANTABILITY
  21. or FITNESS FOR A PARTICULAR PURPOSE.
  22.  
  23.  
  24.                                 Installation
  25.                                 ------------
  26.  
  27.     You'll  need  to install the XPK package first to use this library.  The
  28. XPK  package  should  be available on most Bulletin Board Systems, so try to
  29. get it there.
  30.  
  31.     If  you  already have the  XPK package  installed, add  this  library to
  32. your system simply by copying the xpkRAKE.library  to your LIBS:Compressors/
  33. directory, or  if you've got a 68020 (or greater) processor, you should take
  34. the xpkRAKE.library.68020' instead.
  35.  
  36.  
  37.                                 Description
  38.                                 -----------
  39.  
  40.     RAKE is an  XPK packer sublibrary  which  implements a highly  optimized
  41. form  of  the popular  LZ77 compression  algorithm. It  uses  static huffman
  42. coding   for   the  'len'   and  a  three-step  coding  for   the   'offset'
  43. information.  The  major  feature   of this packer  is the  highly optimized
  44. algorithm for tracking down redundant data.
  45.  
  46.  
  47.     RAKE  supports  four  modes  at  compression.  To  speed up  compression
  48. everytime a better match (than the previous) is found, the 'dictionary' size
  49. will be reduced dynamically according to the pack-mode by division ...
  50.  
  51.  0..25  : by 8, 
  52. 26..50  : by 4,
  53. 51..75  : by 2 (using 'lsr.w', of course).
  54. 76..100 : The  full  dictionary  size  of  approx. 18KB  will  be scanned for
  55.           redundant data.
  56.  
  57. -----------------------------------------------------------------------------
  58.  
  59.     NOTE: There is no need to repack  files packed  with  RAKE  V1.0 - V1.3
  60.           (68000 or 68020 version), because RAKE V1.5 is totally compatible
  61.           with older versions and vice versa, it just works faster.
  62.  
  63. -----------------------------------------------------------------------------
  64.  
  65.  
  66.                                  Statistics
  67.                                  ----------
  68.  
  69.     Following  is  a table  briefly listing some  comparative statistics for
  70. NUKE  and  RAKE.  These  were   generated   by   xBench   on   an   A3000/25
  71. with  2MB ChipMem and 4MB FastMem, using the AmigaVision  executable as data
  72. (standard xpk benchmark configuration).
  73. Note that memory needs don't include  xpkmaster.library's buffers.
  74.  
  75.  
  76.                                                         | Memory usage while
  77. Packer      UComp   Comp    CF     CSpd     USpd        | packing  unpacking
  78. ----------------------------------------------------------------------------
  79. 68020_V1.5 (results from 30-Dec-94 (16Bits - 128K Hashtab))
  80. rake.100   594712 322872 45.8%    86819   660791        |    256K         0K
  81. rake.75    594712 324964 45.4%   100288   653529        |    256K         0K
  82. rake.50    594712 326908 45.1%   111578   653529        |    256K         0K
  83. rake.25    594712 328796 44.8%   119901   646426        |    256K         0K
  84.  
  85. 68000_V1.5 (results from 30-Dec-94 (16Bits - 128K Hashtab))
  86. rake.100   594712 322872 45.8%    82713   512682        |    256K         0K
  87. rake.75    594712 324964 45.4%    94699   508300        |    256K         0K
  88. rake.50    594712 326908 45.1%   104887   508300        |    256K         0K
  89. rake.25    594712 328796 44.8%   111998   503993        |    256K         0K
  90.  
  91. NUKE_V1.0
  92. nuke       594712 326908 45.1%    41472   613105        |    192K         0K
  93.  
  94.  
  95.  
  96.                                   History
  97.                                  ---------
  98.  
  99. Sep-9-94   V1.0 First public release (68000,68020)
  100.  
  101. Sep-14-94  V1.1 BUGFIX: Uncompressable data (or remainder) should not  cause
  102.                         XPKERR_SMALLOUTBUF  but  XPKERR_EXPANSION !
  103.                         (Worst case: OutLen = OutBufLen + 5(<<XPK_MARGIN) :)
  104.  
  105.            V1.2 Not a public release (minor bugfix for xp>K<-handler)
  106.                 (I've got no feedback if xp>K<-handler now works fine
  107.                 (everybody should use xf>H<-handler ;) ).
  108.  
  109. Nov-6-94   V1.3 Using bit-field instructions for 68020 version. Pack-routine
  110.                 now fits in 68020 instruction cache.  Further  optimizations
  111.                 done increasing packing & unpacking speed :-). Memory
  112.                 shortage causes XPKERR_EXPANSION => files won't be packed but
  113.                 be saved uncompressed by XFH without aborting with an error.
  114.  
  115.            V1.4 Not a public release
  116.  
  117. Jan-10-94  V1.5 - Now using MEMF_PUBLIC instead of MEMF_ANY, thus buffers should
  118.                   not be swap by virtual memory programs.
  119.                 - Some optimizations done increasing packing & unpacking speed :)
  120.                   >> Thanks to Denis Ahrens! <<
  121.                 - Now using double of hash-entries without increasing memory usage.
  122.                   (Using .w as offset instead .l as address.)
  123.                   This results in a better packing speed :)
  124.                 - Memory shortage causes RAKE to decrease hash-buffer size 
  125.                   dynamically, until buffer has reached 0.5KB (XPKERR_NOTPACKED will
  126.                   be returned at this time). Same behavior as MASH.
  127.                 - I have forgotten to delete some ';' in my source: RAKE will now
  128.                   stay in memory after usage, sorry.
  129.  
  130.  
  131.                         \\//_ Live long and prosper
  132.  
  133.  
  134.                               Contact Address
  135.                               ---------------
  136.  
  137.              dagefoer@ibr.cs.tu-bs.de (perhaps, insert diana. after @ !?)
  138.                                      OR
  139.                   dagefoer@rzcipa03.rz.tu-bs.de (may expire soon :( )
  140.